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Status of Claims 

1 . This final office action is in reply to the Amendments filed on 25 September 2008. 

2. Claims 14 and 24 have been amended. 

3. Claim 34 has been added. 

4. Claim 18 has been canceled. 

5. Claims 1-17 and 19-34 are currently pending and have been examined. 

Response to Amendments 

6. The objection to claim 24 is withdrawn in light of Applicant's amendments. 

7. The rejection of claim 14 under 35 USC §112, 2 nd paragraph is maintained for the reasons set 
forth below. 

8. The rejection of claim 18 under 35 USC §112, 2 nd paragraph are withdrawn in light of Applicant's 
amendments and the cancellation of that claim. 

Examiner's Note 

9. Examiner notes that claim 1 in the amended claims appears to incorrectly denote that it has been 
amended although no new text is underlined. A comparison with the original claims set however 
indicates that no amended text is present. As such, Examiner interprets claim 1 in the amended 
claims set as being 'original' and not being amended. 

Response to Arguments 

10. Applicant's arguments received on 25 September 2008 have been fully considered but they are 
not persuasive. Referring to the previous Office action, Examiner has cited relevant portions of 
the references as a means to illustrate the systems as taught by the prior art. As a means of 
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providing further clarification as to what is taught by the references used in the first Office action, 
Examiner has expanded the teachings for comprehensibility while maintaining the same grounds 
of rejection of the claims, except as noted above in the section labeled "Status of Claims." This 
information is intended to assist in illuminating the teachings of the references while providing 
evidence that establishes further support for the rejections of the claims. 

11. With regard to the limitations of claims 1-17 and 19-34, Applicant essentially argues that the 
prior art of record, specifically Hanagan and Pather, and in distinction to the instant application, 
do not teach "that the customer billing system processes accounts with a set of dependent tasks. 
Pather fails to make up for the deficiencies of Hanagan with respect to accounts with dependent 
tasks. Pather is directed to a method of processing subscription queries into data by linking 
subscription queries to event data to generate a database of notification data. Notably, Pather 
does not disclose processing subscription queries if there are any interdependency between 
subscription queries." (Remarks, p. 9) Examiner however notes that Hanagan does specifically 
contemplate the processing of "task dependencies" (see Hanagan [0329] " Task dependencies, 
service request dependencies , and resource availability are all taken into account during the 
scheduling process." (emphasis added)). That Pather may or may not teach queries or 
processing "if there are any interdependenc[ies]" is of no moment given that Hanagan does. 
Moreover, Hanagan teaches the processing of task dependencies in a number of contexts (see 
e.g., [0082], [0145], [0239], [0249], [0311], [0329], [0335], [0428] where batch processing is also 
described, [0432] and [0448]. As noted more fully below in the claim rejections, the other 
elements of the claims are also taught by Hanagan and Pather as shown. 

12. Applicant's remarks (Remarks, p.8-9) also suggest that the Applicant is attempting to distinguish 
the instant application from the prior art by reading limitations into the claims from the 
specification. Applicant's references to the facts of the type of task processing performed in the 
prior art, i.e., customer billing system (Hanagan) and subscription queries (Pather), do not 
diminish the fact that the prior art reads on the claims as written. USPTO personnel are to give 
claims their broadest reasonable interpretation in light of the supporting disclosure. In re Morris, 
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127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). Limitations appearing in 
the specification but not recited in the claim should not be read into the claim. E-Pass Techs., Inc. 
v. 3Com Corp., 343 F.3d 1364, 1369, 67 USPQ2d 1947, 1950 (Fed. Cir. 2003) (claims must be 
interpreted "in view of the specification" without importing limitations from the specification into the 
claims unnecessarily). In re Prater, 415F.2d 1393, 1404-05, 162 USPQ 541, 550-551 (CCPA 
1969). See also In re Zletz, 893 F.2d 319, 321-22, 13 USPQ2d 1320, 1322 (Fed. Cir. 1989) 
("During patent examination the pending claims must be interpreted as broadly as their terms 
reasonably allow.... The reason is simply that during patent prosecution when claims can be 
amended, ambiguities should be recognized, scope and breadth of language explored, 
and clarification imposed.... An essential purpose of patent examination is to fashion claims that 
are precise, clear, correct, and unambiguous. Only in this way can uncertainties of claim scope 
be removed, as much as possible, during the administrative process."). 

13. In summary, the Examiner has taken the broadest and most reasonable interpretation of the 
claim limitations as written, in light of the specification. Although the specification may contain 
recitations of intended use, alternative points of view and subjective interpretative differences 
between the prior art of record and the present invention as premeditated, it is the claims 
themselves that are given patentable weight only inasmuch as they are constructed. Because the 
claimed invention has been painted with the broad stroke of petitioning for limitations that 
encompasses more than is asserted in the Applicant's claims, the prior art of record continues to 
fully discloses the Applicant's inventions as claimed. 

14. With regard to new claim 34, see the claim rejections below. 
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Claim Objections 

15. Claim 34 is objected to because of the following minor informalities: the claims recites "an error 
component that that processes..." where one of the double 'that's should be removed. 



Claim Rejections - 35 USC §112 

16. The following is a quotation of the second paragraph of 35 U.S.C. §112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

17. Claims 14 and 34 are rejected under 35 U.S.C. §112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. 

• Claim 14: Applicant uses the phrases self-throttles and predetermined threshold in a manner 
that is incomplete and hence vague and indefinite. Moreover, this merely describes and 
characterizes an effect of unstated method steps. No method steps describe how the system 
is made to speed-up or slow down the system if this is, in fact, what is meant by the term. 
Nor does the specification provide any further insight into how the self-throttling is effected 
(see e.g., Applicant's specification, p. 13). Although Applicant has addressed the issues 
associated with 'threshold' values that were raised in the first non-final office action, Applicant 
has not addressed the methods associated with self-throttling as previously described. For 
purpose of examination, Examiner interprets the term self-throttles, to mean that some 
degree of data alignment is maintained during processing. 

• Claim 34: Applicant recites "wherein the bulk component processes the errored account with 
a predetermined threshold number of attempts to resolve the errored account until the 
account state is in par with the rest of accounts being processed by bulk mode." where it 
unclear and inconsistent that processing occurs "a predetermined threshold number of 
attempts to resolve..." and at the same time processing "until the account state is in par with 
the rest of accounts..." The inconsistency renders this claim vague and indefinite. In 
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addition, stating that processing continues until the account state "is in par" uses a relative if 
not vague term, hence is vague and indefinite based on the use of that phrase. 

Claim Rejections - 35 USC §103 

18. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 

rejections set forth in this Office action: 

A patent may not be obtained though the invention is not identically disclosed or described as 
set forth in section 102 of this title, if the differences between the subject matter sought to be 
patented and the prior art are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to 
which said subject matter pertains. Patentability shall not be negatived by the manner in 
which the invention was made. 

19. Claims 1-17 and 19-33 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Hanagan, ef al. (US PgPub 20040133487 A1) in view of Pather, ef al. (US 7177859 B2). 

Claims 1,6, 7,15, 22, 28 and 31: 

Hanagan describes and/or discloses a system (see title) and method (see e.g., [0004] "billing", 
"aggregates", and in [0082] "determine the tasks...") and computer-readable media with computer- 
executable instructions (claim 3 and [0452] "server programs") that facilitates task processing ([0082]) 
and periodic processing ([0306] "on a periodic basis") of subscription accounts ([0102] "customer 
subscription information") in the following limitations, as shown: 

• a bulk component ([0357] "batch environment") that concurrently processes ([0357] "automatically 
processed in parallel") a plurality of eligible accounts ([041 1] "row is valid" and in [0078] "providing 
advanced features to additionally support scripting and validations ." (emphasis added)) with a set 
of dependent tasks ([0329] "Task dependencies"); and 

• a removal component (Abstract: "The components are modular." and in [0252] "Filters can be set 
up to filter out records. [. . .] Filters are defined using the ERP graphical user interface ." (emphasis 
added) where 'filter out' corresponds to removal and 'ERP...' corresponds to component") that 
removes an account from the eligible accounts as an errored account if an error is associated 
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therewith ([0250] "Single erroneous UE records are errored out and written to an Invalid Event 
Records File. If some records are rejected due to invalid field contents, the reason is written to an 
Error File." (emphasis added) where 'records' corresponds to eligible accounts and 'errored out' 
corresponds to an errored account). 

• an error component ([0149-56] "...in the case an error is detected." See also [0250] "The 
Validator") that that processes the errored account ([0250] "Single erroneous UE records are 
errored out and written to an Invalid Event Records File.") to resolve the error associated 
therewith (see [0250] and [0443] "Error Handling"), and merges the resolved errored account with 
bulk processing ([0250] "A GUI is also provided for error correction . [...] The validated UE records 
are written to files (different files (same format) for assembly and non-assembly records)." 
(emphasis added) where 'validated' corresponds to resolved errored account and 'assembly' 
corresponds to merges... see also [0477] "The framework merges master and incremental 
update files...") of the eligible accounts by the bulk component when the resolved errored 
account is temporally aligned with the bulk processing ([0476] "Over time the master file will get 
out of synchronization with the database because of database inserts, updates or deletions that 
are applied to the database table. For large tables supporting time critical functionality, these 
additional changes are captured periodically and made available to running processes in an 
incremental update file ." (emphasis added) where 'out of synchronization' in conjunction with 
'changes...' and 'incremental update...' corresponds to temporally aligned and 'running 
processes' corresponds to the bulk component and bulk processing); and 

• facilitates real-time processing of an account ([0084] "The invention is a Customer Care and 
Billing (CCB) solution, providing convergent and modular functionality, real-time information , 
drastically shortened time to market, and a flexible architecture."). 

Hanagan does not specifically teach the notion of a catch-up component, per se, but Pather in an 
analogous art pertaining to programming models for subscription services, does. In at least col. 28, 
lines 59-62 ([28,59-62]) "Additionally, developers may specify the number of guan-tums that the 
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logical generator clock can fall behind the real time clock before processing of subscription rules (both 
event and scheduled) is skipped in order to catch up .") 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the modular system models, components and methods of Hanagan that batch 
process subscription and billing accounts with the methods of Pather that provide a mechanism for 
'catching up' because account processing data handled in batches is highly scalable and thus 
merging corrected data, as by the error component, is important so that all accounts can be handled, 
but the error correction processing may cause many accounts to "fall behind" (Pather [28,51]) the 
appropriate processing time frame, hence, the capability to catch up avoids this problem by 
maintaining the timeliness of the data processing. 
Claims 2 and 16: 

Hanagan teaches the following limitation: 

• the tasks are processed sequentially (see [0157] and [0259] "The sequence of calculations...") 
against the plurality of eligible accounts ([0180] "Maintain Customer Accounts") according to task 
dependencies ([0329]). 

Claims 3 and 17: 

Hanagan teaches the following limitation: 

• the bulk component repeatedly processes the errored account a predetermined number of 
attempts before the errored account is removed by the removal component for error processing 
([0247] "A raw event record file is rejected if it contains too many erroneous records (where "too 
many" is specified in a user-defined parameter )..." and in [0283] "the cycle can be approved for 
distribution or rejected to be reprocessed ." (emphasis added) and finally, in [0250] see "error 
correction" and [0476] for "deletions" and removal component)). 

Claims 4 and 23: 

Hanagan teaches the following limitation: 

• merging the errored account ([0250] "Single erroneous UE records are errored out and written to 
an Invalid Event Records File.") that has been resolved with the one or more eligible accounts for 
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further processing in bulk ([0250] "A GUI is also provided for error correction . [...] The validated 
UE records are written to files (different files (same format) for assembly and non-assembly 
records)." (emphasis added) where 'validated' corresponds to errored account that has been 
resolved and 'assembly' corresponds to merging... see also [0477] "The framework merges 
master and incremental update files..."). 
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Claim 5: 

Hanagan teaches the following limitation: 

• the errored account is merged back in only when the errored account has been resolved (see the 
rejections of claims 4 and 23 above. Note the phrase therein that has been resolved... is logically 
equivalent to the condition/limitation only when the...) temporally with processing of the bulk 
component ([0476] "Over time the master file will get out of synchronization with the database 
because of database inserts, updates or deletions that are applied to the database table. For 
large tables supporting time critical functionality, these additional changes are captured 
periodically and made available to running processes in an incremental update file ." (emphasis 
added) where 'out of synchronization' in conjunction with 'changes...' and 'incremental update...' 
corresponds to resolved temporally and 'running processes' corresponds to the bulk component). 

Claim 8: 

Hanagan teaches the following limitation: 

• the dependent tasks processed on a first day must be processed error-free before the same tasks 
can be processed on a succeeding day ([0082]: "The result is a workflow, identifying the proper 
order in which tasks must be completed , the estimated time required to perform a task, and the 
type of resource(s) required for each task. OP 22 actively monitors each task, generating alarms 
for potential error conditions , such as tasks failing to start or finish at their scheduled time. OP 22 
completely automates order scheduling and processing. This eliminates time-consuming errors 
due to missed steps and improper work implementations , freeing valuable resources to perform 
other value." (emphasis added)). 

Claim 9: 

Hanagan does not specifically teach the following limitation, but Pather, in an analogous art pertaining 
to programming models for subscription services, does as shown. 

• comprising a catch-up component for real-time processing of an account (In at least col. 28, lines 
59-62 ([28,59-62]) "Additionally, developers may specify the number of guan-tums that the logical 
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generator clock can fall behind the real time clock before processing of subscription rules (both 
event and scheduled) is skipped in order to catch up .") 

Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the modular system models, components and methods of Hanagan that batch 
process subscription and billing accounts with the methods of Pather that provide a mechanism for 
'catching up' because account processing data handled in batches is highly scalable and thus 
merging corrected data, as by the error component, is important so that all accounts can be handled, 
but the error correction processing may cause many accounts to "fall behind" (Pather [28,51]) the 
appropriate processing time frame, hence, the capability to catch up avoids this problem by 
maintaining the timeliness of the data processing. 
Claims 10 and 19: 

Hanagan teaches the following limitation: 

• the bulk component ([0357] "batch environment") is associated with periodic processing ([0306] 
"on a periodic basis") of the plurality of eligible ([0411] "row is valid" and in [0078] "providing 
advanced features to additionally support scripting and validations ." (emphasis added)) 
(subscriber) accounts ([0102] "customer subscription information"). 
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Claim 11: 

Hanagan teaches the following limitation: 

• the plurality of eligible accounts are processed in parallel by one or more computing devices 
([0268] "ERP [ ] is designed for parallel processing and the workload is balanced between the 
different processes by workload servers ."). 

Claim 12: 

Hanagan teaches the following limitation: 

• the plurality of eligible accounts are processed in parallel by different threads of execution on a 
single computing device ([0396] "On-line application servers are multi-threaded."). 

Claim 13: 

Hanagan teaches the following limitation: 

• the plurality of eligible accounts are processed in accordance with an access control list ([0456] 
regarding data security and "login screens". Also, in [0432] "restrict unauthorized access"). 

Hanagan does not specifically refer to an access control list per se, but Examiner takes Official Notice 
that it is old and well-known as well as common place in the information processing arts to restrict 
access to computer services and information using various standard mechanisms, among these is 
the use of access control lists of authorized users. Therefore, it would have been obvious to one of 
ordinary skill in the art at the time the invention was made to incorporate an access control list and 
process accounts in accordance therewith because preserving data security and integrity is a 
necessary condition for ensuring the utility and the functionality of any large-scale information 
processing system and the utility of such restrictions were predictable at the time of the invention. 
Claim 14: 

Hanagan does not specifically teach the following limitation, but Pather, as shown, does: 

• wherein the system is self-throttled to keep system resources ([23, 23]: "Such a factor can be 
considered a trade-off between improving application speed and monopolizing system 
resources." and corresponds to the effect of self-throttling. In addition, Pather repeatedly refers 
to "a predetermined threshold" (see e.g., [77,23]) under a predetermined threshold ([24,1]: "A 
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value specified for distributor settings should also be considered in terms of a trade-off between 
improving appli-cation speed and monopolizing system resources." (emphasis added) where 'a 
value specified' corresponds to a predetermined threshold.) si the number of dependencies 
associated with an account are below a second threshold. 
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was 
made to use the aforementioned threshold and to self-throttle because it provides a mechanism 
whereby system administrators can effect a tradeoff between speed and system resources as noted 
above and that the benefits of this capability were known at the time of the invention and were 
predictable. 
Claim 20: 

Hanagan teaches the following limitation: 

• the bulk component fetches only the required number of accounts for processing based on the 
set of tasks to be processed ([0415]: "The parts of the invention that operate without direct user 
interaction are called "batch" and "stream I/O". Batch units of workload are initiated periodically, 
usually according to a pre-defined time schedule or by predictable arrival of an occasional event 
or file of events from an external system ." (emphasis added) and in [0416]: " Each batch process 
inherits from the HvfApplication infrastructure class, which provides a context for handling event- 
based processing . [...] This is accomplished by coding a method Process Message that provides 
application-specific handling of asynchronous input queue messages." (emphasis added) where 
the emphasized text indicates an association between various batch (bulk) processes and a 
particular sef of tasks.) 

Claim 21: 

Hanagan teaches the following limitation: 

• the bulk component and the error component process accounts concurrently ([0443]: "Error 
Handling: Error handling allows applications to deal consistently with error or fault situations. 
Error handling for batch applications is different in some respects than for on-line applications 
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since high-volume errors must not stop processing as long as work can continue. On-line errors 
generally must be dealt with immediately ." (emphasis added)). 
Claim 24: 

Hanagan teaches the following limitation: 
• the processing in bulk further comprises, 

• processing task dependency data related to the set of tasks ([0329]: " Task dependencies , 
service reguest dependencies, and resource availability are all taken into account during the 
scheduling process."); 

• maintaining system state data of the system (see [0316] regarding "State Transition 
Knowledge Base"); 

• generating an account level exception list of exceptions generated during 
the processing in bulk (In at least [0162] reference is made to "processing" and "exception 
logic". Further, in [0247] "...the Error Report File..." which is equivalent to an account level 
exception list. Also, in [0443] "Error handling for batch applications..." where this also 
pertains to accounts] as shown in [0081] "The Customer Bill Manager... the mass batch of 
documents."); 

• monitoring and reporting system processes related to at least bulk processing ([0330]: "The 
invention monitors tasks for these conditions and creates alarms that are directed to workers 
to inform them of the problems." (emphasis added)), 

• removing an errored account ([0252] "Filters can be set up to filter out records. [...]" and in 
[0250] "Single erroneous UE records are errored out [. . .]"); and 

• providing error handling related to an error generated by the errored account ([0443]). 
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Claim 25: 

Hanagan teaches the following limitation: 

• reprocessing the errored account in bulk before removing the account for error processing 
(see the rejections of claims 3 and 17). 

Claim 26: 

Hanagan does not specifically teach the limitation reprocessing the errored account before requiring 
manual intervention to initiate further reprocessing, but Examiner takes Official Notice that it is old 
and well-known as well as common place in the workflow processing arts to initiate repeated attempts 
to process a specific task before requiring manual intervention as this increases the likelihood of 
enabling "customer service representatives [to] spend more time focusing on the customer and less 
time on manual and redundant tasks." Hanagan [0078]. Therefore, it would have been obvious to 
one of ordinary skill in the art at the time the invention was made to include the steps of reprocessing 
attempt to mitigate the necessity of manual intervention because this can tend to increase system 
productivity (see e.g., [0328]). 
Claim 27: 

Hanagan teaches the following limitation: 

• predicting when subscription cycle end processing needs to be performed next (See the 
rejection of claim 18 above and [0307]. Also, in [0082]: "OP 22 completely automates order 
scheduling and processing." and in [0415]: "Batch units of workload are initiated periodically , 
usually according to a pre-defined time schedule or by predictable arrival of an occasional 
event or file of events from an external system." (emphasis added) where 'workload...' 
corresponds to subscription cycle end process as in the rejection of claim 18, 'pre-defined...' 
and 'predictable...' and '...event' corresponds to the limitation since scheduling an event or 
task is equivalent to predicting when...). 
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Claim 29: 

Hanagan teaches the following limitation: 

• determining according to a predetermined threshold level when a second account that is 
dependent on a first account is considered inconsistent (Regarding the first and second account 
(dependent on...) in in [0133] "These types of customers are generally large with multiple 
invoices, accounts, and locations." (emphasis added) hence related or dependent accounts. In 
[0250-3]: "The Validator [ ] validates the [ ] records for correctness and [...] performs different 
types of edits on the fields of the internal record format (for example, numeric checks, date 
validations, and value checks). Moreover, the Validator determines which records need to be 
assembled for long duration. An event record file is rejected if it contains too many erroneous 
records (as specified in a parameter ). [...] Several error groups can be defined. [...] The 
importance of the error group determines how to handle the record (for example, ignore the 
incorrectness, recycle the record, or write it to the Invalid Event Records File). The error severity 
can be configured . [...] Corrections can be applied either to individual records, or to multiple 
records grouped by error codes and error groups. [...] A warning is issued when configurable 
specified thresholds are passed .") 
Claim 32: 

Hanagan teaches the following limitation: 

• a first system that processes a set of tasks against a plurality of accounts; a second system 
that processes the same set of tasks against the plurality of accounts; wherein the first 
system signals the second system to bypass processing of one of the plurality of accounts if 
the first system determines an error in the one account ([0163]: "Even when alternative 
processing is used , the event continues along the common path once the exception logic is 
completed ." In [0444]: "This service allows processes to be controlled by a central control 
and management process (C&M). In this case, C&M can start, stop (gracefully or 
immediately) and monitor processes to verify their current state (running or in error )." 
(emphasis added) where 'processes' refers to at least two system elements or systems. In 
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[0250]: "The Validator 176 validates the UE (Unrated Event) records for correctness and 
sends the UE records to the Duplicate Event Check process . [...] An event record file is 
rejected if it contains too many erroneous records (as specified in a parameter). Single 
erroneous UE records are errored out and written to an Invalid Event Records File. [...] The 
importance of the error group determines how to handle the record (for example, ignore the 
incorrectness, recycle the record, or write it to the Invalid Event Records File )" (emphasis 
added) where 'write it to the...' corresponds to bypass processing. Also, in [0475]: " Multiple 
processes can share memory-mapped files. If two processes on the same machine map to 
the same file , the file will be loaded into memory only once." (emphasis added) where 'file' 
corresponds to accounts and 'multiple processes' corresponds to processes a set of tasks...). 



Hanagan teaches the following limitation: 

• the second system signals the first system to bypass processing of another of the plurality of 
accounts if the second system determines an error in the another account (In [0445]: "Using 
special workload balancing processes, message queuing provides a straightforward 
mechanism for load balancing across multiple batch application processes serving the same 
function ." (emphasis added) and see the rejection of claim 32 above.). 
20. Claim 34 is rejected under 35 U.S.C. 103(a) as being unpatentable over Hanagan, et al. (US 
PgPub 20040133487 A1) in view of Pather, et al. (US 7177859 B2) and further in view of 
Seshadri, ef al. (US PgPub 20040002988 A1). 
Claim 34: 

Hanagan teaches the following limitation: 



a bulk component ([0357] "batch environment") that concurrently processes ([0357] 
"automatically processed in parallel") a plurality of eligible accounts ([041 1] "row is valid" and 
in [0078] "providing advanced features to additionally support scripting and validations ." 
(emphasis added)) with a set of dependent tasks ([0329] "Task dependencies"); 
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• a removal component (Abstract: "The components are modular." and in [0252] "Filters can be 
set up to filter out records. [...] Filters are defined using the ERP graphical user interface ." 
(emphasis added) where 'filter out' corresponds to removal and 'ERP...' corresponds to 
component') that removes an account from the eligible accounts as an errored account if an 
error is associated therewith ([0250] "Single erroneous UE records are errored out and 
written to an Invalid Event Records File. If some records are rejected due to invalid field 
contents, the reason is written to an Error File." (emphasis added) where 'records' 
corresponds to eligible accounts and 'errored out' corresponds to an errored account); 

• an error component ([0149-56] "...in the case an error is detected." See also [0250] "The 
Validator") that that processes the errored account ([0250] "Single erroneous UE records are 
errored out and written to an Invalid Event Records File.") to resolve the error associated 
therewith (see [0250] and [0443] "Error Handling"), and merges the resolved errored account 
with bulk processing ([0250] "A GUI is also provided for error correction . [...] The validated 
UE records are written to files (different files (same format) for assembly and non-assembly 
records)." (emphasis added) where 'validated' corresponds to resolved errored account and 
'assembly' corresponds to merges... see also [0477] "The framework merges master and 
incremental update files...") of the eligible accounts by the bulk component when the 
resolved errored account is temporally aligned with the bulk processing ([0476] "Over time 
the master file will get out of synchronization with the database because of database inserts, 
updates or deletions that are applied to the database table. For large tables supporting time 
critical functionality, these additional changes are captured periodically and made available to 
running processes in an incremental update file ." (emphasis added) where 'out of 
synchronization' in conjunction with 'changes...' and 'incremental update...' corresponds to 
temporally aligned and 'running processes' corresponds to the bulk component and bulk 
processing); and 

Hanagan does not specifically teach the notion of a catch-up component, per se, but Pather in an 
analogous art pertaining to programming models for subscription services, does. In at least col. 28, 
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lines 59-62 ([28,59-62]) "Additionally, developers may specify the number of quan-tums that the 
logical generator clock can fall behind the real time clock before processing of subscription rules (both 
event and scheduled) is skipped in order to catch up ."). Neither Hanagan nor Pather specifically 
teach that the bulk component processes the errored account with a predetermined threshold number 
of attempts to resolve the errored account until the account state is in par with the rest of accounts 
being processed by bulk mode, but Seshadri, in an analogous art does. Seshadri [0099] states: "With 
respect to the distributor, it should be noted that retry functionality can be provided wherein the 
platform allows application developers to specify a pattern of retry attempts for failed notifications and 
retrys are implemented accordingly without requiring an application developer to specificy an 
inordinate amount of extra logic." (emphasis added) and in [0338] and [0344] describes a "retry 
schedule" and in [0345] describes an "element [that] can be used to define the number of failures that 
may occur before a system event log entry is created to document the failure." (emphasis added) 
where the emphasized text corresponds to a predetermined threshold number of attempts to resolve 
the errored account. Note that Seshadri also teaches batch processing in at least [0126] and in many 
other paragraphs. Therefore, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made to combine the teaching of Hanagan and Pather with Seshadri because the 
bulk (batch) processing capabilities taught in Seshadri increases the efficiency (Seshadri [0007]) of 
the account processing system and the technical capability to combine these teaching existed at the 
time of the invention and the result was predictable. 
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Conclusion 

Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. 
Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the 
extension of time policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the 
mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this 
final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened 
statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, 
and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the 
advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS 
from the date of this final action. 

Any inquiry of a general nature or relating to the status of this application or concerning this 
communication or earlier communications from the Examiner should be directed to Mark A. Fleischer 
whose telephone number is 571.270.3925. The Examiner can normally be reached on Monday-Friday, 
9:30am-5:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner's 
supervisor, Bradley Bayat whose telephone number is 571.272.6704 may be contacted. 

Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be obtained from 
either Private PAIR or Public PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see 

http://portal.uspto.gov/external/portal/pair <http://pair-direct.uspto.gov >. Should you have questions on 
access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll- 
free). Any response to this action should be mailed to: 

Commissioner of Patents and Trademarks 
P.O. Box 1450 
Alexandria, VA 22313-1450 
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or faxed to 571-273-8300. 

Hand delivered responses should be brought to the United States Patent and Trademark Office 
Customer Service Window: 

Randolph Building 
401 Dulany Street 
Alexandria, VA 22314. 



Mark A. Fleischer 
/Mark A Fleischer/ 
Examiner, Art Unit 3624 



24 December 2008 



/Bradley B Bayat/ 

Supervisory Patent Examiner, Art Unit 3624 



